文末送书 |（三）深入浅出图解Git，入门到精通（保姆级教程）
这一篇我们继续图解Git，上两篇原创图解了Git的基本操作，有兴趣的可以看一看[（一）深入浅出图解Git，入门到精通（保姆级教程）]和[（二）深入浅出图解Git，入门到精通（保姆级教程）]。
这一篇写完基本Git的操作就图解完了，如果想深入了解Git，这里可以推荐一些Git的硬核书籍：【精通Git】、【GitHub入门与实践】、【Git权威指南】、【Git版本控制管理】、【GitHub实践】。
这些都是一些关于Git的比较好的书籍，有兴趣的可以可看一看，网上也有很多电子书。闲话不多说，下面就开始我们的正题。
日志
Git查看日志前面有提到过可以通过git log命令进行查看：
git log可以查看你「提交的时间、提交的作者、以及提交的id」都可以查到，如果你觉得查询的信息太多，可以加上参数--pretty=oneline，只会显示版本号和提交时的备注信息。
如果你想查最近的几条历史记录，可以通过加参数"-n"的形式制定查询几条记录，历史记录是「按照操作的时间」进行排序的：
还可以通过加参数" --graph"，以图形化的形式展示历史记录，方便与查看历史记录与分支的关系：
-p"，可以查看每一个commit操作更改的文件的哪一行，加参数"-stat"查看哪些文件改动了，进行简要的统计。更加详细的git log参数可以查看命令帮助。
Git查看历史记录的另一个命令是git reflog，它可以查看「所有分支的所有操作记录，包括已经删除的commit记录和reset记录」。
衍合(rebase)
分支管理中有「合并」和「衍合」操作，合并操作在在第二年篇的分支章节已经详细讲解过了，就来讲解一下衍合操作：git rebase操作。
假如有两位开发人员Tom和Jerry，Tom和Jerry都把远程的master分支签出到本地，此时当前的Tom和Jerry本地都是只有一条master分支：
branch，并且将新的分支branch推向远程仓库（git push origin branch）：
此时Tom本地仓库和远程仓库的分支保持一致，分支如下图所示：
Tom在自己的分支branch上开发自己的模块，假如开发期间Tom进行了「两次」的提交，最后Tom本地的分支形成如下所示：
也可以通过git log查看两次提交的记录：
所以此时Tom想提交，必须先更新一下自己的本地分支：
Tom中通过git log命令可以查看到Jerry的提交记录情况，说明此时分支已经与远程仓库同步：
此时Tom更新分之后，本地的分支情况如下所致，相比原来master指向c1，现在向前推进了一个版本指向c4：
直接 git merge。先 git rebase，然后git merge。
（1）若是使用第一种方法直接在master分支上执行git merge命令，「Git会把master分支上最新的提交c4的内容和branch分支上最新的提交c3 合并后生成一个新的提交点c5」：
（2）若是使用第二个方法，先master也需要拉取到最新版本，然后是切换到branch分支，这个也就是要切换到rebase的分支，这里指的是branch分支。
在branch分支执行git rebase master，表示chanch上新提交的c4节点会在master上的最新提交点后重新设立起点重新执行，若是有冲突则解决冲突，没有冲突执行git add，最后执行git rebase --continue。
通过git log查看你可以发现，之前branch分支上进行【「删除HELLO ABC」】的操作commit hash已经发生改变，最后切换到master分支，执行git merge master。
通过测试可以发现，原来branch分支上重新commit的节点c4在rebase到master分之后hash发生了改变，并且提交的内容被复制保留，从而使得master分支整个呈现线性的commit记录，而不是直接git merge后的分叉记录。
在master分支进行branch分支rebase的原理图如下：
注意：「一般不是在branch进行rebase主分支master的提交，因为会导致master的新提交在本地丢失，这样有可能会导致本地仓库与远程仓库发生冲突，从而无法push操作」。
「总结」：「git merge会将两个分支的最新提交点进行一次合并，形成一个新的提交点，最终形成树状的提交记录」，但是有些人并不是喜欢merge，觉得merge之后出现的分叉会难以管理，那么可以选择rebase操作来替代merge。
「git rebase操作是将要rebase的分支最新提交点作为新的基础点，将当前执行git rebase master的分支的新commit点重新生成commit hash值，rebase完后再次切换到另一条分支进行合并，就可以保证线性的commit的记录」。
「最后只选择merge还是rebase取决于个人和时机情况，假如你想提交记录呈现线性整洁那么选择rebase，否则选择merge，实际情况也有可能是这样的，每个人本地开发，可能会提交非常的多次，有些提交可能是修一些简单的bug，那么最后的提交只想做一次完整、正确的提交，那么也可以使用rebase。」
标签管理
Git中使用的标签有两种类型：「轻量级的（lightweight）和含附注的（annotated）」。轻量级标签只需在git tag后加上标签的名字，就可以添加标签。
标签管理作为开发人员可能很少使用，可以作为了解，「tag是针对Git中某一时间某一版本打上标签」，tag的使用命令也是非常的简单。
新建标签
新建一个标签，默认是在HEAD新建，可以指定commit id新建，具体命令如下所示：
$ git tag <标签名>
$ git tag <标签名> <commit id>
$ git tag -a <标签名> -m "备注"
删除标签
删除标签若是标签没有推向远程仓库，直接使用以下命令删除：
$ git tag -d <标签名>
若是标签已经推向远程仓库，先删除本地，再删除远程仓库的标签：
$ git tag -d <标签名>
$ git push origin :refs/tags/<标签名>
查看标签
git tag的方式是查看所有的标签，git show <标签名>的方式是查看每个特定的标签
$ git tag
$ git show <标签名>
推送标签到远程
推送标签也是分两种情况，一种是指定标签的推送，另一种是推送所有标签。
$ git push origin <标签名>
$ git push origin --tags
提交了错误代码
代码错误提交了怎么办，重新再一次提交一个版本呗，这个可能是很多人的解决方案，当然Git也是有提供自己的解决方案的命令。
第一种就是再次将修改文件然后git add .到暂存区，最后git commit --amend提交修改 ，它的原理图如下所示：
这种方法只能修改当前HEAD，也就是最新的提交，那么要修改是倒数第二个或者倒数第三个的提交呢？
这时候就要使用rebase -i（「交互式rebase」）进行操作了，这个命令是指定commit链中哪一个commit需要修改。
比如执行命令：git rebase -i HEAD^。它表示的含义就是把当前commit内容rebase到HEAD之前的一个commit上。
若是想直接丢弃最新的commit的修改，则直接使用命令：git reset --hard HEAD^。他表示当前commit往前移动一次。
git rebase -onto HEAD^^ HEAD^ master。他表示的含义就是以倒数第二个为起点，master为终点，rebase到倒数第三个commit上。
最后
好了图解Git操作基本讲解完了，其他的一些细节操作基本都是在基本操作的基础上加参数，详细的参数大家可以参考官网或者相关的书籍。
在公司的实际应用这三篇图解Git操作基本可以应付了，上面说的交互式操作，基本没用过，只做大致的了解，但是之前在面试华为的时候有被问到Git的交互操作。
最后，帮助粉丝Git的进阶，由北京大学出版社赞助给粉丝送福利，送出两本书 「《Git入门到精通》」，最后获得书籍的形式在本文的「留言区前两名的粉丝」可以获得，活动时间到「10/8 18:00 -10/10 12:00」。